The present disclosure generally relates to determining service dependencies for configuration items. The disclosed embodiments relate more specifically to systems, apparatus, methods, and computer program products for identifying, on request, all of the services that depend on a configuration item.
The Information Technology Infrastructure Library (ITIL) is a set of practices for Information Technology (IT) service management that focuses on aligning IT services with the needs of a business. Because the IT services of a business must ultimately meet the demands of the services' customers and users, customers and users are the entry point to the process model. Accordingly, customers and users may become involved in service support by requesting changes and/or updates to the IT services to address certain problems and/or needs. Implementing such changes and/or updates requires the person who is responsible for implementation to define what services depend on any Configuration Item (CI) that is to be changed and/or updated and may initiate a chain of processes that includes: 1) incident management, 2) problem management, 3) change management, 4) release management, and 5) configuration management. That chain of processes is tracked using the Configuration Management Database (CMDB), which contains the details of the CIs in the IT infrastructure and their relationships to each other.
A CI is any component of an IT infrastructure that is under the control of configuration management. CIs can be individually managed and versioned, and they are usually treated as self-contained units for the purposes of identification and change control within the IT infrastructure. The relationships between different CIs are modeled as data structures in the CMDB. Nevertheless, the CMDB is relatively static because, in the ITIL model, the changes to the CMDB may only be made via a formal change management process.
The value of the CMDB is derived from the formal change management process. Under the formal change management process that is required to modify a CMDB, it generally takes three (3) to five (5) days from when the change request is submitted to when the change is implemented. That time is required to allow for careful consideration and review of the change—the objective being to ensure that the change doesn't have any unexpected and/or undesirable effects. Even an emergency change would normally require at least several hours between the change request and implementation. Thus, the CMDB serves as a somewhat static reference standard of the CIs and their relationships within an IT infrastructure.
Although attempts have been made to increase the speed at which CIs are updated in a CMDB utilizing automated discovery tools, those discovery tools still take between fifteen (15) minutes to an hour to perform a discovery cycle and update the CMDB. Moreover, those discovery tools implement repeated discovery cycles that provide un-controlled inputs to the CMDB such that there is no formal change control to ensure that the CMDB maintains its integrity. Moreover, the relationships in the CMDB still lag behind the changes in the environment that the CMDB attempts to describe.
For example, in a production environment, several virtual servers may be moved from one host to another over a few minutes, completely changing their relationships to the physical machines hosting them and to the network infrastructure connecting them. They may even move between Data Centers. As a result, the data in a CMDB that describes the service model could be completely incorrect if such a change occurs during the fifteen (15) minutes to an hour that it takes to perform a discovery cycle and update the CMDB. And taking down a CI for maintenance may be very costly if done without an accurate understanding of the other CIs that will be effected.